Real-time analysis of application programming interfaces

ABSTRACT

Systems and methods disclosed herein may include real-time analysis of application programming interfaces (APIs). The method may include detecting that the programming code input is associated with at least a portion of an application programming interface (API). At least one coding error associated with the API may be detected based on static analysis of the code. The static analysis may include receiving an indication of a browser version, and comparing the received code with programming code for the API verified for the browser version, to detect the at least one coding error. Information identifying at least a first remediation action for correcting the at least one coding error may be received based at least in part on the at least one browser version. The at least a first remediation action may be provided for display to a user of the computing device.

BACKGROUND

Modern integrated development environments (IDEs) provide a number oftools to facilitate the tasks of writing code, detecting problems in thegrammar or syntax of the code, and fixing problems. When web developerswrite code, they typically target web pages or applications associatedwith a specific web browser (or browsers).

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

In accordance with one or more aspects, a computing device may include aprocessing unit, memory, and a display. The computing device may beconfigured to perform operations for real-time analysis of applicationprogramming interfaces (APIs). The operations may include receiving aselection of at least one browser version from a plurality of browserversions available in an integrated development environment (IDE).Programming code input is received. The operations may further includedetecting that at least a portion of the programming code input isassociated with an application programming interface (API).Compatibility of the API with the at least one browser version may bedetermined. An indication of the determined compatibility of the API maybe provided (e.g., the indication may be provided while receiving and/ordisplaying the programming code input).

In accordance with one or more aspects, a method for real-time analysisof application programming interfaces (APIs) may include, in response toat least receiving programming code input, detecting the programmingcode input is associated with at least a portion of an applicationprogramming interface (API). At least one coding error associated withthe API may be detected based on static analysis of the receivedprogramming code input. The static analysis may include receiving anindication of at least one browser version for a browser associated withimplementing the programming code. The static analysis may furtherinclude comparing the received programming code with programming codefor the API verified for the at least one browser version, to detect theat least one coding error. Information identifying at least a firstremediation action for correcting the at least one coding error may bereceived based at least in part on the at least one browser version. Theat least a first remediation action may be provided (e.g., in real-time)for display to a user of the computing device.

In accordance with one or more aspects, a computer-readable storagemedium having instructions thereon for performing a method for real-timeanalysis of application programming interfaces (APIs) is provided. Themethod may include receiving a selection of a browser version for abrowser used in an integrated development environment (IDE). At least aportion of programming code input can be detected that it is associatedwith an application programming interface (API). Static analysis of theprogramming code input may be performed using a static analysis engineat the computing device, to detect at least one coding error associatedwith the API. Compatibility data indicating whether the programming codeinput associated with the API is compatible with the browser version,may be received from a compatibility analysis engine. While displayingat least a portion of the programming code input, a first indication ofthe at least one coding error and a second indication of thecompatibility data may be provided for display.

As described herein, a variety of other features and advantages can beincorporated into the technologies as desired.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system in which real-time analysis ofapplication programming interfaces (APIs) discussed herein can be used.

FIG. 2 is a block diagram illustrating an example compatibility analysisengine, in accordance with one or more embodiments.

FIG. 3 is a block diagram of a solutions database used in connectionwith compatibility analysis, in accordance with one or more embodiments.

FIG. 4 is a flow diagram illustrating example detection of an API, inaccordance with one or more embodiments.

FIG. 5 is a flow diagram illustrating example static analysis andcompatibility analysis for an entered API, in accordance with one ormore embodiments.

FIG. 6 is a flow diagram illustrating example compatibility analysis foran API, in accordance with one or more embodiments.

FIGS. 7-8 are flow diagrams illustrating example real-time analysis ofapplication programming interfaces (APIs), in accordance with one ormore embodiments.

FIG. 9 is a diagram of an example computing system, in which somedescribed embodiments can be implemented.

FIG. 10 illustrates a generalized example of a suitable cloud-supportedenvironment, in which described embodiments, techniques, andtechnologies may be implemented.

FIG. 11 is an example mobile device that can be used in conjunction withthe technologies described herein.

DETAILED DESCRIPTION

A common problem for web developers in an IDE is that it is often timesdifficult to know in advance which application programming interfaces(APIs) are supported by which browsers (API compatibility information isgenerally not available to the web developer while writing code, unlessa limited set of APIs is used). Using an incompatible and untested APImay result in the finished product (e.g., web page or application)working with one browser but have issues with another browser. To solvethis problem, a web developer will typically search the web forreference web sites and other reference materials describing whichbrowsers support a given API. This task will result in substantialdelays and interruption of the programming workflow of the developer.The web developer may also complete the product using a given API andthen test the finished product against different browsers. However, thisprocessing flow will also result in additional delay and inefficienciesas the developer has to perform additional testing/verification andresolve any issues (e.g., programming errors or “bugs”) discoveredduring the testing. Additionally, some programming languages, such asHTML, JavaScript and CSS, are being continuously updated and there maybe no easy verification step or a single set of APIs to build againstwhen using these languages. Therefore, the need exists for a solutionthat provides efficient ways to verify and conform APIs in an integrateddevelopment environment.

As described herein, various techniques and solutions can be applied toperform real-time analysis of application programming interfaces (APIs).More specifically, static analysis of a detected API may be performed todetermine whether the API (as entered) has any coding errors, andwhether or not it can be used as entered. The static analysis may beimplemented as a code analyzer engine that utilizes data from the cloud(e.g., one or more databases of available APIs for one or moreprogramming languages and/or browsers, coding errors database, etc.) Asthe developer enters programming code, the API static analysis may beperformed in real-time, and any detected coding error may be highlighted(as well as one or more suggested solutions to the coding errors may beprovided). In addition to the static analysis, a compatibility analysismay be performed based on a compatibility of the detected API with abrowser version. For example, a browser version may be selected by thedeveloper (or it may be indicated in a developer profile or as part ofthe programming code that is entered). The detected/entered API may beanalyzed to determine whether the API (or one or more portions of theAPI) are compatible with the selected browser version (or versions). Thecompatibility analysis may be performed in real-time (e.g., concurrentlywith, or subsequent to, the static analysis), and results of thecompatibility analysis may be provided to the developer while the codeis being entered (e.g., real-time highlighting or another type of outputof what portion of the API is compatible with, and what portion is notcompatible with, the indicated browser version). The compatibilityanalysis may be performed by a dedicated engine or by the staticanalysis engine, using one or more of the cloud resources used forstatic analysis and/or other resources used to determine APIcompatibility.

The resources used for the compatibility and static analyses (e.g., theavailable APIs database, database of API coding errors, a solutionsdatabase and so forth) may be implemented locally (e.g., at the clientdevice) and/or in the cloud (e.g., at a server computer communicativelycoupled to the client computing device). Additionally, such resourcescan be kept updated periodically so that the most up-to-date versions ofthe available APIs and other data resources are being utilized for thestatic and compatibility analyses. In this regard, web developers mayimprove upon using a static core API (e.g., a limited set of APIsavailable to the programmer where verification and coding error checkmay be performed at the time of programming but only against thelimited, and not up-to-date, static core API data). More specifically,using the techniques described herein, a web developer may use a dynamiccore API (e.g., an API which may be continuously changing/updatingbetween different browsers and between different browser versions of thesame browser)

The above static/compatibility analysis functions may be part of areal-time API analysis (RTAA) engine (or service), which may beimplemented as a stand-alone application (or app), as part of anexisting web development application, and/or as part of a deviceoperating system (“OS”).

As used herein, the term “application programming interface” (or API)refers to a set of programming instructions for accessing a web-basedsoftware application, a web tool or a service. In this regard, an API issource code interface that a computer system or a program libraryprovides in order to support requests for services from a softwareapplication. An API can be specified in terms of a programming languagethat can be compiled at application build time.

FIG. 1 illustrates an example system in which real-time analysis ofapplication programming interfaces (APIs) discussed herein can be used.The system 100 includes a computing device 102, which can be any of avariety of types of devices, although typically is a mobile device. Forexample, the computing device 102 can be a smart phone or other wirelessphone, a laptop or netbook computer, a tablet or notepad computer, awearable computer, a mobile station, an entertainment appliance, anaudio and/or video playback device, a game console, an automotivecomputer, and so forth. The computing device 102 is typically referredto as being a mobile device because the device 102 is designed orintended to be moved to multiple different locations (e.g., taken by auser with him or her as the user goes to different locations).

The device 102 may further comprise a main processor (or CPU) 117,memory 116, input/output (I/O) subsystem 118, a communication subsystem122, a display 120, and a sensory subsystem 124. The device 102 may berunning an operating system (OS) 104, and may also implement one or moredata stores, such as an API database 130, and a real-time API analysis(RTAA) module 106.

The main processor 117 may comprise suitable logic, circuitry,interfaces, and/or code that may be operable to process data, and/orcontrol and/or manage operations of the computing device 102, and/ortasks and/or applications performed therein in connection with real-timeAPI analysis functions described herein. In this regard, the mainprocessor 117 may be operable to configure and/or control operations ofvarious components and/or subsystems of the computing device 102 byutilizing, for example, one or more control signals. The main processor117 enables running and/or execution of applications, programs and/orcode, which may be stored, for example, in the system memory 116. Insome instances, one or more of the applications running and/or executingon the computing device 102 (e.g., the RTAA engine 106) may generateand/or update video content that may be rendered via the display 120.

The system memory 116 may comprise suitable logic, circuitry,interfaces, and/or code that may enable permanent and/or non-permanentstorage, buffering, and/or fetching of data, code and/or otherinformation, which may be used, consumed, and/or processed. In thisregard, the system memory 116 may comprise different memorytechnologies, including, for example, read-only memory (ROM), randomaccess memory (RAM), Flash memory, solid-state drive (SSD), and/orfield-programmable gate array (FPGA). The system memory 116 may store,for example, configuration data, which may comprise parameters and/orcode, comprising software and/or firmware.

The communication subsystem 122 may comprise suitable logic, circuitry,interfaces, and/or code operable to communicate data from and/or to thecomputing device 102, such as via one or more wired and/or wirelessconnections and the network 146. The communication subsystem 122 may beconfigured to support one or more wired protocols (e.g., Ethernetstandards, MOCA, etc.) and/or wireless protocols or interfaces (e.g.,CDMA, WCDMA, TDMA, GSM, GPRS, UMTS, EDGE, EGPRS, OFDM, TD-SCDMA, HSDPA,LTE, WiMAX, WiFi, Bluetooth, and/or any other available wirelessprotocol/interface), facilitating transmission and/or reception ofsignals to and/or from the computing device 102, and/or processing oftransmitted or received signals in accordance with applicable wired orwireless protocols. In this regard, signal processing operations maycomprise filtering, amplification, analog-to-digital conversion and/ordigital-to-analog conversion, up-conversion/down-conversion of basebandsignals, encoding/decoding, encryption/decryption, and/ormodulation/demodulation. In accordance with an embodiment of thedisclosure, the communication subsystem 122 may provide wired and/orwireless connections to, for example, the server computer 152 (e.g., acloud server computer) implementing the compatibility analysis engine110, via the network 146. The network 146 may include the Internetand/or one or more wired and/or wireless networks.

The sensory subsystem 124 may comprise suitable logic, circuitry,interfaces, and/or code for obtaining and/or generating sensoryinformation, which may relate to the computing device 102, its user(s),and/or its environment. For example, the sensory subsystems 124 maycomprise positional or locational sensors (e.g., GPS or other GNSS basedsensors), ambient conditions (e.g., temperature, humidity, or light)sensors, and/or motion related sensors (e.g., accelerometer, gyroscope,pedometers, and/or altimeters).

The I/O subsystem 118 may comprise suitable logic, circuitry,interfaces, and/or code for enabling user interactions with the device102, enabling obtaining input from user(s) and/or to providing output tothe user(s). The I/O subsystem 118 may support various types of inputsand/or outputs, including, for example, video, audio, and/or textual. Inthis regard, dedicated I/O devices and/or components, external to orintegrated within the computing device 102, may be utilized forinputting and/or outputting data during operations of the I/O subsystem118. Exemplary I/O devices may comprise one or more built-in cameras(e.g., front-facing and/or rear-facing camera), one or more displays(e.g., display 120), mice, keyboards, touchscreens, voice inputinterfaces, and other input/output interfaces or devices. With respectto video outputs, the I/O subsystem 118 may be operable to generateand/or process video content, graphics, and/or textual data, and/orgenerate video frames based thereon for display, via the display 120 forexample.

The display 120 may comprise suitable logic, circuitry, interfacesand/or code that may enable displaying of video content, which may behandled and/or processed via the I/O subsystem 118. The display 120 maybe used in outputting data during real-time API analysis by the RTAAengine 106.

The RTAA module 106 may comprise suitable circuitry, interfaces, logicand/or code and may be implemented as a service (or an engine) runningas part of the OS 104, as part of another application running on thedevice 102, and/or as a stand-alone application (separately from the OS104). The RTAA engine 106 may further use browser preferences 112, astatic analysis engine 108, and a compatibility analysis engine 110.Even though the RTAA engine 106 is illustrated separate from the staticanalysis engine 108 and the compatibility analysis engine 110, thedisclosure is not limited in this regard and the engines 108-110 may beimplemented as part of the RTAA engine 106.

The static analysis engine (SAE) 108 may comprise suitable circuitry,interfaces, logic and/or code and may be operable to perform staticanalysis for an API (e.g., a complete API that has been entered via thedevice 102 or at least a portion of a known API). The SAE 108 maydetermine whether an API has been entered (or whether a portion of aknown API has been entered at the device 102), and whether any codingerrors are present in the API as entered. In this regard, the SAE 108may use one or more databases to perform the API recognition and codingerror detection functionalities. For example, the SAE 108 may use theAPI database 130 to detect an API that is being entered by a user ofdevice 102 (e.g., via the entered programming code 142), and/or one ormore of the databases 154-156 used by the compatibility analysis engine110.

The compatibility analysis engine (CAE) 110 may comprise suitablecircuitry, interfaces, logic and/or code and may be operable to performcompatibility analysis for one or more APIs in real-time. Morespecifically, the CAE 110 may detect whether an API that is beingentered by a user (or an API that has been entered) of device 102 iscompatible with one or more selected browsers (or browser versions)(e.g., as indicated by the browser preferences 112). The compatibilitydetermination by the CAE 110 (as well as the static analysis by the SAE108) may be performed in real-time, e.g., while a user of device 102 isentering programming code 142 for an API.

In accordance with an example embodiment, the CAE 110 (and/or the SAE108) may be implemented in a cloud computing environment, e.g., on aserver computer 152 that is communicatively coupled to device 102 viathe network 146. As illustrated in FIG. 1, the CAE 110 may beimplemented as a stand-alone device (e.g., peripheral of the server 152)using a separate CPU 158 and memory 160, or the CAE 110 may beimplemented within the server 152 (e.g., running as a separateapplication and/or as part of the server OS). The CAE 110 may furthercomprise the API database 130, a coding errors database 154, a solutionsdatabase 156, and API usage data 159. The coding errors database 154 mayinclude information on various coding errors for a given API, based onprogramming language and/or browser version. The solutions database 156may include information on one or more solutions (or remediationactions), which may be performed in order to fix/remediate a givencoding error and/or browser incompatibility issue detected by the SAE108 and/or the CAE 110. The API usage data 159 may provide statisticaldata regarding use of a given API used with a specified programminglanguage and for a specified browser version.

FIG. 2 is a block diagram illustrating an example compatibility analysisengine, in accordance with one or more embodiments. Referring to FIG. 2,there is illustrated a more detailed diagram of the compatibilityanalysis engine 110. More specifically, the coding errors database 154and the solutions database 156 may each include a private databasecomponent (e.g., 206, 208) and a public database component (210, 212).Alternatively, the private database components 206 and 208 may form aprivate database 204, and the public database components 210 and 212 mayform a public database 204 (each of the databases 204 and 202 includingcoding errors and solutions data). The private databases 204 may beprivate to the cloud environment of the server computer 152, and onlydevices that are connected to the cloud environment (or a customers ofone or more services offered by the cloud environment) may access theprivate databases 204. The public databases 202 may include data that ispublicly available (e.g., on one or more web sites) and is aggregatedinto the public databases 202. Both the public and private databases maybe periodically updated by, e.g., the server computer 152 (e.g.,automatically and at a pre-determined interval).

The API database 130 within the compatibility analysis engine 110 mayfurther comprise data identifying APIs organized based on, e.g., browserversion, programming language or other criteria. For example, the APIdatabase 130 may include information 220, . . . , 222 identifyingavailable APIs for browsers (or browser versions) 1, N, respectively.Similarly, the API database 130 may include information 230, . . . , 232identifying available APIs for programming languages 1, K, respectively.

In accordance with an example embodiment, one or more of the databaseswithin the compatibility analysis engine 110 (or the entire engine 110)may be implemented within the computing device 102.

FIG. 3 is a block diagram of a solutions database used in connectionwith compatibility analysis, in accordance with one or more embodiments.Referring to FIG. 3, there is illustrated a more detailed view of thesolutions database 156 within the compatibility analysis engine 110.More specifically, the solutions database 156 may include a plurality ofdifferent types of solutions, which may be offered by the RTAA engine106 and provided for display to the user/programmer entering theprogramming code 142. Some example solutions may include arecommendation 302 for not using the corresponding API that is beinganalyzed by the RTAA engine 106; a suggested alternative API 304 (e.g.,an API with similar functionality as the currently analyzed API but withbetter compatibility results with the desired/selected browser version);one or more corrections 306 to the current API (e.g., corrections toremedy one or more identified coding errors or compatibility issues);and one or more libraries 308 for use with the current API (e.g., theremay be available libraries which can be used together with the API toachieve desired functionalities while ensuring compatibility with theselected browser version). Even though only four solutions areillustrated in FIG. 3, the present disclosure is not limited in thisregard and other solutions may be used as well.

FIG. 4 is a flow diagram illustrating example detection of an API, inaccordance with one or more embodiments. Referring to FIGS. 1-4, theexample method 400 may start at 402, when text input may be received.For example, a user (e.g., web developer) may enter programming code 142using device 102. At 404, the RTAA engine 106 may determine (e.g., inreal-time, as the programming code 142 is received) whether the textinput (or programming code 142) matches a known API (or a part of aknown API). The API detection functionality may be performed by thestatic analysis engine 108 and/or the compatibility analysis engine 110,using the API database 130. At 406, the detected API may be output(e.g., displayed on the device screen 120) or otherwise stored forfurther processing (e.g., stored in memory 116 and further analysis maybe performed, such as compatibility analysis).

FIG. 5 is a flow diagram illustrating example static analysis andcompatibility analysis for an entered API, in accordance with one ormore embodiments. Referring to FIG. 5, the example method 500 may startat 502, when a browser version information is obtained. For example, auser may have specified a browser preference 112 (e.g., of a specificbrowser or browser version), or a browser preference (e.g., browserversion 144) may be indicated with the programming code 142.

At 504, text input for generating the API may be received at 504. Forexample, the programming code 142 may be entered via the device 102. At506, the text input may be compared with a known definition of an APIfor the selected browser version. For example, the RTAA engine 106 (orthe static analysis engine 108) may compare the entered programming code142 with APIs within the API database 130 (e.g., one or more of the APIs220, . . . , 222 associated with the selected browser version orversions).

At 508, it may be determined whether the programming code 142 has anyerrors based on the comparison with the known definition of the API forthe selected browser version. If there are no detected errors,processing may continue at 512. If errors are detected, at 510, thestatic analysis engine 108 may display the errors (e.g., highlight theincorrect portion of the entered programming code 142) as well as asuggested solution (e.g., from the solutions databases 208, 212).Additional programming input may then be received to correct theindicated errors (e.g., using the suggested solution).

In reference to FIG. 1, the static analysis engine 108 may analyze theprogramming code 142 and determine that an API 148 is being entered atthe device 102. Additionally, the static analysis engine 108 maydetermine that a coding error 150 is present within the entered code142.

For example, the entered code 142 may include the following API:

<input type=“date” name=“bday”>.

The static analysis engine 108 may determine that entered API has acoding error (e.g., the incorrect tags of “date” and “bday” may behighlighted), and the correct API (e.g., suggested solution) is thefollowing API compatible with IE11:

<input type=“text” name=“lastname”>.

As another example of coding errors, the entered code 142 may includethe following API:

Website.prototype.display = function ( ) {  this.clearPage( ); this.func= setFunc(function( ) { this.resetPage( ); }, 0); };

The static analysis engine 108 may detect a coding error 150, and mayindicate the following replacement API as a suggested solution:

Website.prototype.display = function ( ) { Var self = this; self.clearPage( );  self.func = setFunc(function( ) { self.resetPage();  }, 0); };

As another example of coding errors, the entered code 142 may includethe following part of an API:

“X=10”.

However, the static analysis engine 108 may determine that “X” has notbeen defined, the above entered code may be highlighted, and thefollowing solution may be provided as a suggested correction:

“Var X=10”.

As another example of coding errors, the entered code 142 may includethe following part of an API:

return { ‘name’ : ‘Oren, }

However, the static analysis engine 108 may determine that the above APIpattern is incorrect, and the following solution may be provided as asuggested correction:

Return { ‘name’ : ‘Oren, }

In reference to FIG. 5, the compatibility processing may be performedstarting at 512. More specifically, the RTAA engine 106 (and/or thestatic analysis engine 108) may communicate the detected API 148, thebrowser version 144, and/or the coding error 150 to the compatibilityanalysis engine 110. The CAE 110 may perform API compatibility analysisin real-time (with real-time highlighting of incompatible portions ofthe API), based on compatibility of the API (or the entered API code)with the selected browser version 144. After the compatibility analysisis complete, API analysis information 170 may be sent back to the device102. The API analysis information may include one or more detectedincompatible portions of the API and/or one or more suggested solutions(e.g., correction in the API or a replacement API).

In an example embodiment, the API analysis information 170 may includeAPI usage data 159 for the API 148. In this regard, the API analysisinformation may provide one or more solutions to detected coding errorsand/or incompatibility, and the usage data 159 may indicate how popular(e.g., how many users or percent of users have implemented) thesuggested solution (or solutions).

At 514, it may be determined whether the entire API has been entered,and if it has not, real-time analysis (e.g., static and compatibility)analysis may continue as the user/programmer is entering additional code142. If the API has been entered, then a final confirmation of acompliant API may be provided at 516 (or an indication of one or moredetected incompatible portions in the entered API).

As another example of compatibility analysis and remediation of adetected incompatibility, the entered code 142 may include the followingAPI for showing the width and height of a browser window:

Width=window.innerWidth;

Height=window.innerHeight.

The browser version 144 may indicate version 11 of Internet Explorer(IE11). The CAE 110 may determine that the entered API is unsupported byIE11, a coding error 150 can be indicated (e.g., the entered API may behighlighted), and the following suggested solution may be provided as avalid IE11 API:

Width=document.documentElement.clientWidth;

Height=document.documentElement.clientHeight.

In an example embodiment, the API analysis information 170 may includestatic analysis and/or compatibility analysis

FIGS. 6-8 are flow diagrams illustrating example real-time analysis ofapplication programming interfaces (APIs), in accordance with one ormore embodiments. Referring to FIGS. 1-3 and 6, the example method 600may start at 602, when a selection of at least one browser version froma plurality of browser versions available in an integrated developmentenvironment (IDE) is received. For example, the computing device 102receives the browser version input 144. At 604, the computing device 102may receive the programming code input 142. At 606, the RTAA engine 106(which may include the engines 108, 110) may detect at least a portionof the programming code input 144 is associated with an applicationprogramming interface (API) (e.g., API 148). The API 148 may include theAPI as entered with the programming code 142 without any static analysiscorrections, or after static analysis (and any suggested corrections)have been performed. At 608, the compatibility engine 110 may determinecompatibility of the API (e.g., the entered API 148) with the at leastone browser version (e.g., 144). At 610, an indication of the determinedcompatibility of the API (e.g., as received with the API analysisinformation 170) may be provided. For example, such indication may beprovided while receiving the programming code input 144 (or at a timethat is substantially close to a time that the programming code has beenreceived).

Referring to FIGS. 1-3 and 7, the example method 700 may start at 702,when the RTAA engine 106 (including the engines 108, 110) in response toat least receiving programming code input, may detect that enteredprogramming code input (e.g., 142) is associated with at least a portionof an application programming interface (API) (e.g., 148). At 704, theRTAA engine 106 (or the SAE 108) may also detect at least one codingerror (e.g., 150) associated with the API based on static analysis ofthe received programming code input 142. In some instances, thedetection of the programming code input and the coding error may beperformed in real-time, while the programming code 142 is beingreceived. The static analysis (e.g., as performed by the SAE 108) mayinclude receiving (at 706) an indication (e.g., 144 or an indicationfrom the preferences 112) of at least one browser version for a browserassociated with implementing the programming code. At 708, the SAE 108and/or the CAE 110 may compare the received programming code 142 withprogramming code for the API verified for the at least one browserversion, to detect the at least one coding error (e.g., 150). At 710,the RTAA engine 106 may receive information (e.g., 170) identifying atleast a first remediation action (e.g., selected from the solutionsdatabase 156) for correcting the at least one coding error, theremediation action selection based at least in part on the at least onebrowser version. At 712, the at least a first remediation action may beprovided (e.g., in real-time) for display to a user of the computingdevice.

Referring to FIGS. 1-3 and 8, the example method 800 may start at 802,when the RTAA engine 106 may receive a selection of a browser version(e.g., 144 or based on the preferences 112) for a browser used in anintegrated development environment (IDE). At 804, the RTAA engine 106may detect at least a portion of the programming code input 142 isassociated with an application programming interface (API) (e.g., API148). At 806, the RTAA engine 106 may use a static analysis engine(e.g., 108), to perform static analysis of the programming code input142 to detect at least one coding error (e.g., 150) associated with theAPI. At 808, the RTAA engine 106 may receive (e.g., from a compatibilityanalysis engine 110), compatibility data (e.g., API analysis information170) indicating whether the programming code input 142 associated withthe API is compatible with the selected browser version (e.g., 144). At810, a first indication of the at least one coding error (e.g., 150) anda second indication of the compatibility data (e.g., 170) may beprovided (e.g., for display) at the device 102, while displaying atleast a portion of the programming code input 142. In some instances,the first indication of the at least one coding error (e.g., 150) and asecond indication of the compatibility data (e.g., 170) may be provided(e.g., for display) at the device 102, while the programming code input142 is being received (or within a time period after the code input hasbeen received).

FIG. 9 is a diagram of an example computing system, in which somedescribed embodiments can be implemented. The computing system 900 isnot intended to suggest any limitation as to scope of use orfunctionality, as the innovations may be implemented in diversegeneral-purpose or special-purpose computing systems.

With reference to FIG. 9, the computing system 900 includes one or moreprocessing units 910, 915 and memory 920, 925. In FIG. 9, this basicconfiguration 930 is included within a dashed line. The processing units910, 915 execute computer-executable instructions. A processing unit canbe a general-purpose central processing unit (CPU), processor in anapplication-specific integrated circuit (ASIC), or any other type ofprocessor. In a multi-processing system, multiple processing unitsexecute computer-executable instructions to increase processing power.For example, FIG. 9 shows a central processing unit 910 as well as agraphics processing unit or co-processing unit 915. The tangible memory920, 925 may be volatile memory (e.g., registers, cache, RAM),non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or somecombination of the two, accessible by the processing unit(s). The memory920, 925 stores software 980 implementing one or more innovationsdescribed herein, in the form of computer-executable instructionssuitable for execution by the processing unit(s).

A computing system may also have additional features. For example, thecomputing system 900 includes storage 940, one or more input devices950, one or more output devices 960, and one or more communicationconnections 970. An interconnection mechanism (not shown) such as a bus,controller, or network interconnects the components of the computingsystem 900. Typically, operating system software (not shown) provides anoperating environment for other software executing in the computingsystem 900, and coordinates activities of the components of thecomputing system 900.

The tangible storage 940 may be removable or non-removable, and includesmagnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any othermedium which can be used to store information and which can be accessedwithin the computing system 900. The storage 940 stores instructions forthe software 980 implementing one or more innovations described herein.

The input device(s) 950 may be a touch input device such as a keyboard,mouse, pen, or trackball, a voice input device, a scanning device, oranother device that provides input to the computing system 900. Forvideo encoding, the input device(s) 950 may be a camera, video card, TVtuner card, or similar device that accepts video input in analog ordigital form, or a CD-ROM or CD-RW that reads video samples into thecomputing system 900. The output device(s) 960 may be a display,printer, speaker, CD-writer, or another device that provides output fromthe computing system 900.

The communication connection(s) 970 enable communication over acommunication medium to another computing entity. The communicationmedium conveys information such as computer-executable instructions,audio or video input or output, or other data in a modulated datasignal. A modulated data signal is a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia can use an electrical, optical, RF, or other carrier.

The innovations can be described in the general context ofcomputer-executable instructions, such as those included in programmodules, being executed in a computing system on a target real orvirtual processor. Generally, program modules include routines,programs, libraries, objects, classes, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The functionality of the program modules may be combined or splitbetween program modules as desired in various embodiments.Computer-executable instructions for program modules may be executedwithin a local or distributed computing system.

The terms “system” and “device” are used interchangeably herein. Unlessthe context clearly indicates otherwise, neither term implies anylimitation on a type of computing system or computing device. Ingeneral, a computing system or computing device can be local ordistributed, and can include any combination of special-purpose hardwareand/or general-purpose hardware with software implementing thefunctionality described herein.

For the sake of presentation, the detailed description uses terms like“determine” and “use” to describe computer operations in a computingsystem. These terms are high-level abstractions for operations performedby a computer, and should not be confused with acts performed by a humanbeing. The actual computer operations corresponding to these terms varydepending on implementation.

FIG. 10 illustrates a generalized example of a suitable cloud-supportedenvironment 1000, in which described embodiments, techniques, andtechnologies may be implemented. In the example environment 1000,various types of services (e.g., computing services) are provided by acloud 1010. For example, the cloud 1010 can comprise a collection ofcomputing devices, which may be located centrally or distributed, thatprovide cloud-based services to various types of users and devicesconnected via a network such as the Internet. The implementationenvironment 1000 can be used in different ways to accomplish computingtasks. For example, some tasks (e.g., processing user input andpresenting a user interface) can be performed on local computing devices(e.g., connected devices 1030, 1040, 1050), while other tasks (e.g.,storage of data to be used in subsequent processing) can be performed inthe cloud 1010.

In example environment 1000, the cloud 1010 provides services forconnected devices 1030, 1040, 1050 with a variety of screencapabilities. Connected device 1030 represents a device with a computerscreen 1035 (e.g., a mid-size screen). For example, connected device1030 could be a personal computer such as desktop computer, laptop,notebook, netbook, or the like. Connected device 1040 represents adevice with a mobile device screen 1045 (e.g., a small size screen). Forexample, connected device 1040 could be a mobile phone, smart phone,personal digital assistant, tablet computer, and the like. Connecteddevice 1050 represents a device with a large screen 1055. For example,connected device 1050 could be a television screen (e.g., a smarttelevision) or another device connected to a television (e.g., a set-topbox or gaming console) or the like.

One or more of the connected devices 1030, 1040, and/or 1050 can includetouchscreen capabilities. Touchscreens can accept input in differentways. For example, capacitive touchscreens detect touch input when anobject (e.g., a fingertip or stylus) distorts or interrupts anelectrical current running across the surface. As another example,touchscreens can use optical sensors to detect touch input when beamsfrom the optical sensors are interrupted. Physical contact with thesurface of the screen is not necessary for input to be detected by sometouchscreens. Devices without screen capabilities also can be used inexample environment 1000. For example, the cloud 1010 can provideservices for one or more computers (e.g., server computers) withoutdisplays.

Services related to API analysis can be provided by the cloud 1010through the real-time API analysis service (RTAAS) 1020, or throughother providers of online services (not depicted). The RTAAS 1020 mayhave functionalities similar to the RTAAS 106 as described herein.Additionally, the cloud 101 may be used to implement a compatibilityanalysis engine (CAE) 1021, which may have functions similar to the CAE110.

In the example environment 1000, the cloud 1010 provides one or more ofthe technologies and solutions described herein to the various connecteddevices 1030, 1040, and/or 1050 using, at least in part, the RTAAS 1020.

FIG. 11 is an example mobile device that can be used in conjunction withthe technologies described herein. Referring to FIG. 11, the examplemobile device 1100 may include a variety of optional hardware andsoftware components, shown generally at 1102. Any components 1102 in themobile device 1100 can communicate with any other component, althoughnot all connections are shown, for ease of illustration. The mobiledevice 1100 can be any of a variety of computing devices (e.g., cellphone, smartphone, handheld computer, Personal Digital Assistant (PDA),etc.) and can allow wireless two-way communications with one or moremobile communications networks 1104, such as a cellular, satellite, orother network.

The illustrated mobile device 1100 can include a controller or processor1110 (e.g., signal processor, microprocessor, ASIC, or other control andprocessing logic circuitry) for performing such tasks as signal coding,data processing, input/output processing, power control, and/or otherfunctions. An operating system 1112 can control the allocation and usageof the components 1102 and support for one or more application programs1114. The application programs can include common mobile computingapplications (e.g., email applications, calendars, contact managers, webbrowsers, messaging applications), or any other computing application.

The illustrated mobile device 1100 can include memory 1120. Memory 1120can include non-removable memory 1122 and/or removable memory 1124. Thenon-removable memory 1122 can include RAM, ROM, flash memory, a harddisk, or other well-known memory storage technologies. The removablememory 1124 can include flash memory or a Subscriber Identity Module(SIM) card, which is well known in GSM communication systems, or otherwell-known memory storage technologies, such as “smart cards.” Thememory 1120 can be used for storing data and/or code for running theoperating system 1112 and the applications 1114. Example data caninclude web pages, text, images, sound files, video data, or other datasets to be sent to and/or received from one or more network servers orother devices via one or more wired or wireless networks. The memory1120 can be used to store a subscriber identifier, such as anInternational Mobile Subscriber Identity (IMSI), and an equipmentidentifier, such as an International Mobile Equipment Identifier (IMEI).Such identifiers can be transmitted to a network server to identifyusers and equipment.

The mobile device 1100 can support one or more input devices 1130, suchas a touchscreen 1132, microphone 1134, camera 1136, physical keyboard1138 and/or trackball 1140, and one or more output devices 1150, such asa speaker 1152 and a display 1154. Other possible output devices (notshown) can include piezoelectric or other haptic output devices. Somedevices can serve more than one input/output function. For example,touchscreen 1132 and display 1154 can be combined in a singleinput/output device.

The input devices 1130 can include a Natural User Interface (NUI). AnNUI is any interface technology that enables a user to interact with adevice in a “natural” manner, free from artificial constraints imposedby input devices such as mice, keyboards, remote controls, and the like.Examples of NUI methods include those relying on speech recognition,touch and stylus recognition, gesture recognition both on screen andadjacent to the screen, air gestures, head and eye tracking, voice andspeech, vision, touch, gestures, and machine intelligence. Otherexamples of a NUI include motion gesture detection usingaccelerometers/gyroscopes, facial recognition, 3D displays, head, eye,and gaze tracking, immersive augmented reality and virtual realitysystems, all of which provide a more natural interface, as well astechnologies for sensing brain activity using electric field sensingelectrodes (EEG and related methods). Thus, in one specific example, theoperating system 1112 or applications 1114 can comprisespeech-recognition software as part of a voice user interface thatallows a user to operate the device 1100 via voice commands. Further,the device 1100 can comprise input devices and software that allows foruser interaction via a user's spatial gestures, such as detecting andinterpreting gestures to provide input to a gaming application.

A wireless modem 1160 can be coupled to an antenna (not shown) and cansupport two-way communications between the processor 1110 and externaldevices, as is well understood in the art. The modem 1160 is showngenerically and can include a cellular modem for communicating with themobile communication network 1104 and/or other radio-based modems (e.g.,Bluetooth 1164 or Wi-Fi 1162). The wireless modem 1160 is typicallyconfigured for communication with one or more cellular networks, such asa GSM network for data and voice communications within a single cellularnetwork, between cellular networks, or between the mobile device and apublic switched telephone network (PSTN).

The mobile device can further include at least one input/output port1180, a power supply 1182, a satellite navigation system receiver 1184,such as a Global Positioning System (GPS) receiver, an accelerometer1186, and/or a physical connector 1190, which can be a USB port, IEEE1394 (FireWire) port, and/or RS-232 port. The illustrated components1102 are not required or all-inclusive, as any components can be deletedand other components can be added.

In an example embodiment of the disclosure, the mobile device 1100 mayfurther include a real-time API analysis engine (RTAAE) 1116, which maybe separate from or implemented as part of the operating system 1112,the applications 1114, and/or the device processor 1110. The RTAAE 1116may have functionalities similar to the RTAAE 106, as described herein.

Although the operations of some of the disclosed methods are describedin a particular, sequential order for convenient presentation, it shouldbe understood that this manner of description encompasses rearrangement,unless a particular ordering is required by specific language set forthbelow. For example, operations described sequentially may in some casesbe rearranged or performed concurrently. Moreover, for the sake ofsimplicity, the attached figures may not show the various ways in whichthe disclosed methods can be used in conjunction with other methods.

Any of the disclosed methods can be implemented as computer-executableinstructions or a computer program product stored on one or morecomputer-readable storage media and executed on a computing device(e.g., any available computing device, including smart phones or othermobile devices that include computing hardware). Computer-readablestorage media are any available tangible media that can be accessedwithin a computing environment (e.g., one or more optical media discssuch as DVD or CD, volatile memory components (such as DRAM or SRAM), ornonvolatile memory components (such as flash memory or hard drives)). Byway of example and with reference to FIG. 10, computer-readable storagemedia include memory 1020 and 1025, and storage 1040. By way of exampleand with reference to FIG. 11, computer-readable storage media mayinclude memory and storage 1120, 1122, and 1124. The term“computer-readable storage media” does not include signals and carrierwaves. In addition, the term “computer-readable storage media” does notinclude communication connections (e.g., 1070, 1160, 1162, and 1164).

In accordance with an example embodiment of the disclosure, a method mayinclude tracking one or more geo-fences using a GNSS (e.g., GPS)hardware processor within a computing device. The tracking may use atleast one GNSS (e.g., GPS) signal. State changes of the one or moregeo-fences during the tracking may be saved in a shared state database.The shared state database may be shared between the GNSS hardwareprocessor and an application processor within the computing device. Upondetecting a deterioration of the at least one GNSS signal, tracking theone or more geo-fences using the GNSS hardware processor may be switchedto tracking the one or more geo-fences using the application processor.After the switching, an initial state of each of the one or moregeo-fences may be set using states currently stored in the shared statedatabase prior to the switching.

In accordance with another example embodiment of the disclosure, acomputing device may include a GNSS (e.g., GPS) hardware processorconfigured to track one or more geo-fences using at least one GNSS(e.g., GPS) signal; an application processor configured to take overtracking the one or more geo-fences upon deterioration of the at leastone GNSS signal; and a shared state database configured to store statechanges of the one or more geo-fences during the tracking. The sharedstate database may be shared between the GNSS hardware processor and theapplication processor. Upon switching from tracking the one or moregeo-fences using the GNSS hardware processor to tracking the one or moregeo-fences using the application processor, the application processormay be operable to set an initial state of each of the one or moregeo-fences using states currently stored in the shared state databaseprior to the switching. Upon detecting an improvement of the at leastone GNSS signal, tracking the one or more geo-fences using theapplication processor may be switched to tracking the one or moregeo-fences using the GNSS hardware processor. After the switching back,an initial state of each of the one or more geo-fences may be set usingthe states currently stored in the shared state database prior to theswitching back.

Any of the computer-executable instructions for implementing thedisclosed techniques as well as any data created and used duringimplementation of the disclosed embodiments can be stored on one or morecomputer-readable storage media. The computer-executable instructionscan be part of, for example, a dedicated software application or asoftware application that is accessed or downloaded via a web browser orother software application (such as a remote computing application).Such software can be executed, for example, on a single local computer(e.g., any suitable commercially available computer) or in a networkenvironment (e.g., via the Internet, a wide-area network, a local-areanetwork, a client-server network (such as a cloud computing network), orother such network) using one or more network computers.

For clarity, only certain selected aspects of the software-basedimplementations are described. Other details that are well known in theart are omitted. For example, it should be understood that the disclosedtechnology is not limited to any specific computer language or program.For instance, the disclosed technology can be implemented by softwarewritten in C++, Java, Pert, JavaScript, Adobe Flash, or any othersuitable programming language. Likewise, the disclosed technology is notlimited to any particular computer or type of hardware. Certain detailsof suitable computers and hardware are well known and need not be setforth in detail in this disclosure.

Furthermore, any of the software-based embodiments (comprising, forexample, computer-executable instructions for causing a computer toperform any of the disclosed methods) can be uploaded, downloaded, orremotely accessed through a suitable communication means. Such suitablecommunication means include, for example, the Internet, the World WideWeb, an intranet, software applications, cable (including fiber opticcable), magnetic communications, electromagnetic communications(including RF, microwave, and infrared communications), electroniccommunications, or other such communication means.

The disclosed methods, apparatus, and systems should not be construed aslimiting in any way. Instead, the present disclosure is directed towardall novel and nonobvious features and aspects of the various disclosedembodiments, alone and in various combinations and sub combinations withone another. The disclosed methods, apparatus, and systems are notlimited to any specific aspect or feature or combination thereof, nor dothe disclosed embodiments require that any one or more specificadvantages be present or problems be solved.

The technologies from any example can be combined with the technologiesdescribed in any one or more of the other examples. In view of the manypossible embodiments to which the principles of the disclosed technologymay be applied, it should be recognized that the illustrated embodimentsare examples of the disclosed technology and should not be taken as alimitation on the scope of the disclosed technology. Rather, the scopeof the disclosed technology includes what is covered by the scope andspirit of the following claims.

What is claimed is:
 1. A computing device, comprising: a processingunit; memory; and a display; the computing device configured to performoperations for real-time analysis of application programming interfaces(APIs), the operations comprising: receiving a selection of at least onebrowser version from a plurality of browser versions available in anintegrated development environment (IDE); receiving programming codeinput; detecting at least a portion of the programming code input isassociated with an application programming interface (API); determiningcompatibility of the API with the at least one browser version; andproviding an indication of the determined compatibility of the API. 2.The computing device of claim 1, wherein the operations furthercomprise: detecting the at least one browser version from the receivedprogramming code input.
 3. The computing device of claim 1, wherein theoperations further comprise: retrieving verified programming code forthe API; and comparing the received programming code input with theverified programming code.
 4. The computing device of claim 3, whereinthe operations further comprise: detecting at least one coding errorbased on the comparing.
 5. The computing device of claim 4, wherein theoperations further comprise: determining at least one remediation actionbased on the detected at least one coding error; and while receiving atleast a portion of the programming code input, providing the at leastone remediation action for display by the computing device.
 6. Thecomputing device of claim 1, wherein the operations further comprise:communicating the at least one browser version and the at least aportion of the programming code input identifying the API to a remoteserver computer; and receiving from the remote server computer APIanalysis information, wherein the determining of the compatibility isbased on the API analysis information.
 7. The computing device of claim6, wherein the API analysis information comprises at least one of thefollowing: information identifying one or more browsers compatible withthe API; information identifying at least another version of the API,the at least another version compatible with the at least one browserversion; or at least one library for inclusion with the API, wherein theAPI using the at least one library is compatible with the at least onebrowser version.
 8. A method, implemented at least in part by acomputing device, for real-time analysis of application programminginterfaces (APIs), the method comprising: in response to at leastreceiving programming code input: detecting the programming code inputis associated with at least a portion of an application programminginterface (API); detecting at least one coding error associated with theAPI based on static analysis of the received programming code input,wherein the static analysis comprises: receiving an indication of atleast one browser version for a browser associated with implementing theprogramming code; and comparing the received programming code withprogramming code for the API verified for the at least one browserversion, to detect the at least one coding error; receiving based atleast in part on the at least one browser version, informationidentifying at least a first remediation action for correcting the atleast one coding error; and providing the at least a first remediationaction for display to a user of the computing device.
 9. The methodaccording to claim 8, further comprising: receiving access to aplurality of APIs compatible with the at least one browser version; andcomparing the at least a portion of the API with the plurality of APIs.10. The method according to claim 9, further comprising: receivingprogramming code for at least one new API compatible with the at leastone browser version; and updating the plurality of APIs with the atleast one new API.
 11. The method according to claim 9, furthercomprising: determining incompatibility of the API associated with theprogramming code input with the at least one browser version for thebrowser based on the comparison of the at least a portion of the APIwith the plurality of APIs.
 12. The method according to claim 11,wherein determining the incompatibility of the API with the at least onebrowser version is further based at least in part on the at least onecoding error.
 13. The method according to claim 11, further comprising:determining at least a second remediation action for remediating theincompatibility.
 14. The method according to claim 13, wherein thesecond remediation action comprises at least one of the following: arecommendation not to use the API; a recommendation to use analternative API from the plurality of APIs; a recommendation comprisingat least one change to the received programming code input, the at leastone change resulting in compatibility of the API with the at least onebrowser version; and a recommendation to use at least one library withthe API, wherein a combination of the API with the at least one libraryis compatible with the at least one browser version.
 15. The methodaccording to claim 13, further comprising: providing in real-time, theat least a second remediation action for display to the user of thecomputing device.
 16. A computer-readable storage medium storingcomputer-executable instructions for causing a computing device toperform a method for analysis of application programming interfaces(APIs), the stored instructions comprising: instructions to receive aselection of a browser version for a browser used in an integrateddevelopment environment (IDE); instructions to detect at least a portionof programming code input is associated with an application programminginterface (API); instructions to use a static analysis engine at thecomputing device, performing static analysis of the programming codeinput to detect at least one coding error associated with the API;instructions to receive from a compatibility analysis engine,compatibility data indicating whether the programming code inputassociated with the API is compatible with the browser version; andwhile displaying at least a portion of the programming code input:providing for display, a first indication of the at least one codingerror; and providing for display, a second indication of thecompatibility data.
 17. The computer-readable storage medium accordingto claim 16, wherein at least a portion of the compatibility analysisengine is implemented in a second computing device communicativelycoupled to the computing device.
 18. The computer-readable storagemedium according to claim 17, the stored instructions further comprisinginstructions to communicate all of the following information to thecompatibility analysis engine at the second computing device: thedetected at least one coding error; information identifying the API; andthe browser version.
 19. The computer-readable storage medium accordingto claim 16, wherein the first indication comprises highlighting the atleast one coding error, and the stored instructions further comprise:instructions to provide for display with the first indication, anotification of at least one remediation action for remediating the atleast one coding error.
 20. The computer-readable storage mediumaccording to claim 17, the stored instructions further comprising:instructions to access by the static analysis engine at least one remotedatabase to perform the static analysis, the remote database comprisingAPI compatibility data associated with a plurality of programminglanguages and/or a plurality of web browsers.